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LIST OF ABBREVIATIONS 


ASATS 

Automatic Status and Tracking System 

DAPTS 

A subset of the ASATS data base which contains 
segment descriptions. 

EOF 

End-of-file 

FLOCON 

A subset of the ASATjS data, base which contains 
acquisition descriptions l and history. 

F4P 

The FORTRAN -IV- Plus compiler. 

ID 

Identification. 

LAC IE 

Large Area Crop Inventory Experiment. 

RECID 

Record identification field in RIMS data base 
records. 

RIMS 

Regional Information Management System. 

TIRF 

Transmittal/Information Request Form. 
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1. INTRODUCTION 


1.1 PURPOSE AND SCOPE 

This document describes the functional design characteristics 
of the PDP 11/45 LAC IE Phase II/III Status and Tracking System. 
This System will provide mechanisms to support the management 
of LAC IE imagery processing and associated evaluation material. 
For each package of such material ,i the System will maintain a 
record containing the history and the present status and 
location of the package as that package follows its track from 
one LAC IE processing station to another. The System will 
provide means for generating reports on status information and 
on statistical data about the flow of material through the 
LACIE stations. 

The ASATS design is based upon achieving maximum use of the 
Regional Information Management System (RIMS) to perform 
ASATS functions. The functional design is described in terms 
of (1) data base design, (2) new RIMS software built to simplify 
implementation of ASATS, (3) software designed foi ASATS which 
runs independently of RIMS, and (4) a method for constructing 
standard ASATS reports. 

This document also describes plans for testing and operation 
of the System. 
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1.2 BACKGROUND 


A version of the ASATS is currently operational on the 
COMSHARE* s computer system. It was developed using the 
COMPOSIT 77 data management system. In order to reduce the 
cost of operating ASATS, it is being implemented on the PDP 11/45. 

In order that the transition from pne computer system to 
another cause minimal impact, the standard update procedures 
(including update card formats) and standard reports must be 
as nearly identical as possible. Because a different data 
management system is used for the PbP 11/45 and COMSHARE 
version, the ad hoc query and update processes will be different. 
But the PDP 11/45 version will provide similar capabilities 
for ad hoc query and update. Implementation of the PDP 11/45 
version is based upon the same requirement document (LbC-B67b) 
that was previously used for implementing the COMSHARE version 
of ASATS. 


1.3 SYSTEM DESCRIPTION 


ASATS will operate on the POP 11/45 using the Regional Infor- 
mation System (RIMS). It will use the RSX 11-D Version 6.01 
operating system. ASATS System hardware retirements include: 

t 

• POP 11/45 with a minimum of 64K of storage (32K for RSX 
and 32K for RIMS and ASATS) 

• Disk storage (size requirement depends upon the number 
of data base records) 

a TTY compatible terminal for interactive work 

• Card reader for standard update and reports 
a Printer 

a Card punch (requirement may be satisfied by off line 
capability) 

a Two magnetic tape units 

ASATS software requirements include: 

a RSX-11D version 6.01 operating system 

a FORTRAN IV-Plus (F4P) compiler for software maintenance 

a Regional Information Management System (RIMS) 

The ASATS software will be composed df (1) special processors 
built for ASATS to facilitate the auditing of ASATS 
data base updates, (2) RIMS commands augmented to support 
specific ASATS requirements and (3) command files (sequences of 
RIMS commands) which will cause the generation of specified 
reports, (4) data base definitions describing the ASATS data 
base to RIMS and (5) format descriptions describing input 
files and report formats. 
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2. APPLICABLE DOCUMENTS 


The following documents are applicable: 

• Large Area Crop Inventory Experiment (LaCIE) Phase III 
Automatic Status and Tracking System Specifications 
dated August 1976 (document LEC-8675, JSC-11401) 

e RIMS Design Document 

e RIMS Maintenance Document 

e RIMS User Document, dated August 16, 1976 

• TIRF Nc. 76-0085 


3. DESIGN 


3.1 GENERAL 

An overall picture of the PDP 11/45 Status and Tracking System 
is shown in Figure 3-1. The arrows in the diagram indicate 
flow of information. 

Figures 3-2 through 3-fc show the System in more detail and 
illustrate the data paths which satisfy the major requirements 
specified for the System as described in the following sections. 

3.1.1 STANDARD UPDATE PROCESSING 

Handling of standard batch mode daily update cards is shown 
in Figure 3-2. The Preprocessor is a set of operations 
specially designed for the ASATS update card formats. The 
Preprocessor produces some of the required audit listings of 
the input cards and rearranges the input for proper processing 

by RIMS. RIMS makes the required updates to the data base 

* 

and produces a file of information concerning all attempted 
updates. A postprocessor uses that information to produce 
the rest of the required reports on attempted updates and to 
punch the cards required by certain updates. 

3.1.2 STANDARD REPORT GENERATION 

Batch mode production of standard System reports is illustrated 
in Figure 3-3. For each of the standard reports there will be 
a "canned” stream of RIMS commands to collect the information 
required for the report and put it into proper order. Selection 
of different reports as desired is made by different cards in 
the batch input control of RIMS. 

3.1.3 AD HOC QUERY AND UPDATE 

The generalized data management capability of RIMS can be used 



FIGURE 3-1 

AUTOMATIC STATUS AND TRACKING SYSTEM - OVERALL VIEW 
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FIGURE 3-2 

AUTOMATIC STATUS AND TRACKING SYSTEM 
STANDARD UPDATE PROCESSOR SUBSYSTEM 
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for several different purposes, as shown in Figure 3>4. 

Demand production of one-of-a-kind reports can be done through 
an interactive terminal or in batch mode controlled by cards. 

In either batch or interactive mode, RIMS can read a command 
stream or data file brought ir from tape or produced by other 
processes. Information extracted jy RIMS from the data base 
can be printed as a report or displayed at the interactive 
terminal or it can be used as input for other programs which 
might perform special analysis beyond the capabilities of 
RIMS itself. Some of the data flow paths shown in Figure 3-4 
may be restricted for some users, as will be described in 
section 3. 1.4. 2. 

3.1.4 DATA BASE INTEGRITY 

3.1.4. 1 Checkpoint - Restart Data Base Recovery 

In spite of all economically feasible controls over hardware, 
software and procedures, the data base is vulnerable to damage 
or total destruction from such causes as computer system mal- 
function, flaws in physical storage media, or accidental 
running of improper updates. Figure 3-5 illustrates procedures 
which will minimize the time and effort required to put the 
data base back in its proper form after being damaged. 

As shown, the data base will be dumped to magnetic tape 
periodically (once per day, after making all of the day's 
updates, is suggested; the time interval can be adjusted after 
gaining some experience with failure frequency for this system) . 
These "checkpoint" dumps on tape will be stored off-line, 
while the active data base is altered by batch and interactive 
updates on following days. If the active data base is damaged 
or lost, a checkpoint dumped tape (the most recent one 
dumped before the failure) will be read back to on-line storage, 
which restores a previous day's active data base. That restored 
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FIGURE 3-4 

AUTOMATIC STATUS AND TRACKING SYSTEM - 
AD HOC QUERY AND REPORT SUBSYSTEM 
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ASATS DATA BASE 



FIGURE 3-5 

ASATS - CHECKPOINT - RECOVERY PROCESS 
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data base must then be modified by' any batch-mode card updates 
and any ad-hoc updates which have been made since the time 
the checkpoint dump was taken. Making those updates will 
bring the active data base to the condition it should have 
had if no failure had occurred. 

3. 1.4. 2 Access Control 

Accidental or malicious damage to the data base will be mini- 
mized by controls which allow data base modifications to be 
made only by authorized personnel. Some users may produce 
reports without having permission to alter the data base. 

For these users, controls built into the RIMS software will 
restrict data flow to the paths shown in Figure 3-6. As 
shown, the permanent files of the active data base can be read 
by a restricted user, but not written. Writing of temporary 
files required to collect information for report production 
will still be allowed. A password system will be used to 
identify users with unrestricted read-write access to the en- 
tire data base. 
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FIGURE 3-6 

ASATS - ACCESS CONTROL IN AD-HOC REPORT GENERATION 
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3.2 DATA BASE DESIGN 


The data base for ASATS contains two primary kinds of data 
records. Bach DAPTS record contains information about a 
segment that is pertinent to all acquisitions for that segment. 
The fields of the DAPTS records are described in Table 3-1. 

Bach FLOCON record contains information about one particular 
acquisition and the processing of acquisition material 
packages by the LACIE work stations. The FLOCON records 
are described in Table 3-2, 

The system will maintain two physically separate data bases, 
one for LACIE Phase II and one for LACIE Phase III. Bach 
data base will contain both DAPTS and FLOCON records. In 
addition, RIMS uses the data base to store information about 
the data base: format records (as described in RIMS documenta- 

tion) for data records and for input and output records. 
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Name 


3-1.-0APTS RECORD FORMAT 


Description ' 


segment nunber 
LACIE phase indicator 
coiaitry designator 
region 


■r 1 "" 1 " ■■■■ ■ 

End I Key Source 
(Char) Card 


stratun 

global designator 
wheat variety 
priority code 

segment type 

* 

biowindow 1 open (start date) 
biowindow 1 close (end date) 
biowindow 2 open 
biowindow 2 close 
biowindow 3 open 

biowindow 3 close 
biowindow 4 open 
biowindow 4 close 
date topo map received 
date crop calendar received 

date ancillary data received 
segment status character 
time of last change to this 
record 


* 

X 2 

* 

2 












TABLE 3-2.-FLOCON RECORD FORMAT 


Field 

Name 

Description 

Length 

(Char) 

Start 

(Char) 

End 

(Char) 

Key 

Source 

Card 

SEG 

segment number 

4 

1 

4 

X 

B 

LPl 

LACIE phase indicator 

1 

5 

5 


B 

UATACQ 

acquisition date 

4 

6 

9 

X 

B 

BW 

biowindow 

1 

10 

10 

X 

B 

FF 

film flag 

1 

11 

11 


B 

CURS 

current station/status 

1 

12 

12 


(last) 

CURCOM 

current comment 

20 

13 

32 


(last) 

TAPE 

GSFC tape number 

6 

33 

38 


B 

GSFC 

GSFC processing date 

4 

39 

42 


B 

CANI 

CQI update date 

4 

43 

46 


B 

LPDLCOMP 

date film products received 
from LPDL 

4 

47 

50 


G 

AICOMP 

date segment ready for 
CAMS pickup 

4 

51 

54 


H 

♦* 

PACKREC 

date packet received by CAMS 

4 

55 

58 


I 

RUNSUB 

date FDB/batch data processing 
request submitted 

4 

59 

62 


J 

RUNCT 

run count 

4 

63 

66 


(J) 

PRODREC 

date batch products received 
by CAMS 

! 

4 

67 

70 


K 

REWORK 

date rework begun 

4 

71 

74 


M 

RWKCT 

rework count 

4 

75 

78 


(M) 

TOCAS 

date to CAS 

4 

79 

82 


X 

CAMSBP 

CAMS biophase 

3 

83 

85 


X 

CATG 

CAMS evaluation category 

2 

86 

87 


X 

LSD 

time of last change to this 
record 

. 

6 

88 

93 


(last 

up- 

date) 
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3.3 RIMS MODIFICATIONS 


This section identifies the new commands which are being imple- 
mented as part of RIMS to support ASATS. Those commands are 

catagorized as follows: 

a. Special Update Command - This command was defined because 
of the requirement to implement ASATS on the PDP 11/45 
with no changes of input from the form for ASATS on 
COMSHARE using Composit 77. The command will process 

all standard ASATS input cards. 

b. Commands to Support Elimination of Redundant Data - The data 
base for ASATS has a hierarchical relationship between 
DAPTS records and FLOCON records. Commands to create a 
set of related FLOCON records for DAPTS and to create a 
set of related DAPTS records for FLOCON records will be 
provided. Also, a command for displaying records contain- 
ing data from both a FLOCON record and a DAPTS record 

will be provided. 

c. Access Control Command - A command for delivering and 
specifying access control will be provided. Also, the 
system will include a modification to require a user to 
identify himself with his access control word at the be- 
ginning of a session. 

d. Computation Command - This command will allow the user to 
sum fields, field differences, compute mean, and compute 
standard deviations for a set of records. 

e. Header Control Commands - Commands will be provided to 
allow the user to specify report headers in a simpler 
manner and to provide textual description for the number 
of entries in a set. 
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3.3.1 ASATS STANDARD DATA BASE UPDATES 

This section describes design for ASATS data base update. It 
includes a description of an update command built specifically 
for ASATS. It also describes the use of input formats for 
specifying processing for individual record types. 

3. 3. 1.1 Special Update Command 

Purpose: Updates data base from set of input cards. Specific 

update operations are a function of card type (specified in 
second character of each card), data base format, and the 
input format. The input format and the data base to be used 
are a function of the card type and LAC IE phase. 

Inputs: 

e Command: Processing is begun by a UP command 

e Status and tracking input cards: Any of the 19 types 

of ASATS update cards are processed sequentially until 
an EOF (except the Q card, which is handled by the Preprocessor) 

• EOF: Processing of an input file is ended by an 0 

card type (inserted by the Preprocessor) . 

Outputs: Besides updating the ASATS data base, the following 

information is recorded sequentially on a file: 

e Rejected input cards 

e Required DAPTS record does not exist (for ", 2, 3, 4, 

5, and 6 cards) 

e Required PLOCON record does not exist 
e PLOCON record has not reached required state for 
particular type of card. 

e Accepted input cards which create! new DAPTS records. 


Processing: The required processing is e function of card 

type. Card types are categorized as follows: 

e Category 1 * card types *, 2, 3 (in sets) 

e Category 2 - card types *, 2, 4, 5 and 6 

e Category 3 - card type 3 

e Category 4 - card type B 

e Category S - other card types 

t 

A generalized function for adding new records and updating 
existing records will exist. This function, which is driven 
by input formats, data base formats, and card type, will add 
or modify the specified record. The general steps of processing 
input cards are: 

e Read input card 

e Generate record 10 

e Generate external (input) format ID from table 

e Retrieve record 

e Retrieve formats 

e Hither add or update record 
e Output card image reflecting success or error 

\ . i 

Figure 3-7 depicts the flow of this process and variations 
dependent upon category of card type. 

Taole 3-4 indicates the data used for generating a record 
depending on input category. The input format is a function 
of the card type. Table 3-4 also indicates the action to be 
taken upon a record retrieval failure. 


3-15 











\ 


Special Update Processor Flow 
(Continued) 

Figure 3*7 
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Failure^ 
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not exist 
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Generate 

Biowindow 

Table 


Add Record 
Yes 
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File 


Set Flag 
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Special Update Processor Flow 
(Continued) 

Figure 3-7 


3-18 



TABLE 3-3. -INPUT TRANSLATION TABLE FOR GENERATING SEGMENT 

STATUS CHARACTER 


9) 

3 
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The input processing for all fields of each card type is defined 
in the ASATS requirements documents, except for Segment Status 
Character in DAPTS records and Acquisition Status character 
in FLOCON records. Table 3-3 will be used to set the segment 
status character. The Acquisition Status Character is set 
to the card type. These fields are used for generating the 
current station and status. Their use is described in 
Section 3.6. 

1 

The type of operation, an add ora modify, to be performed is a 
function of record type and whether or not a record already 
exists. The input format for the card type identifies the 
fields it updates and the field’s data type. Table 3-5 de- 
scribes the processing for field types on input. 



TABLE 3-5. -USE OF DATA TYPES ON INPUT 
Processing 

Alpha - update associated data base field as 
alpha 

** 

Integer - update associated data base field as 
integer (standard RIMS data type, but not used 
for ASATS) 

Set data base field from table according to 
card type 

Set data base. field value from status table 
according to card type and existing value 

Alpha but don't update data base when input 
blank 

Record I.D. field (no action) 

Increment data base field value by 1 on input 
(Integer field) 

Reject input if associated data base field is 
blank 

Set data base value as a function of biowindow 
table and acquisition date 

Set data base field value from comment table 
according to card type 


3-22 


If an error condition occurs when processing an input card, 
an error type is put in column 80 when the image is written to the 
message file. The input card images for new DAPTS records are 
also written to the message file; column 80 is blank for them. 

Additional processing required by category 3 is the selection 
of FLOCON records of the same segment and the updating of their 
biowindow fields. 

3. 3. 1.2 Use of Input Formats 

An input format is required to describe certain processing 
associated with each record type. This description includes: 

• Identification of each field affecting the update 
process 

e Type identification of each field, which defines how 

the field affects the update process (see section 3. 3. 1.1). 
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• Starting location and length of each field of information 
on the data card (it should be noted that some fields 
affect the processing, but do not exist on the data 
card, therefore do not have a starting location and length). 

The field names used must correspond to the field names used 
in the data base definition (see section 3.2). Field location 
and field use on input cards are described in the ASATS 
requirements documents. 

Implementation using input format definitions allots for simple 
accommodation of most types of changes in input requirements. 

The addition of a new card type would require a modification 
of tables within the special update command processor, g and 3 
type input cards do have codes which are unique to them. 


E 
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3.3.2 SPECIAL COMMANDS FOR ANNOTATING REPORTS 

A new command (header) allows the user to include text which 
is not a part of the data base and to include printer carriage 
controls. Another new command is included which allows the 
user to print a set count with text which he specifies. 

3*3. 2.1 Header Command 

Purpose: To insert header or comment on report 

Input: HD N, Text 

where: HD is command hame 

N is the number of input lines (1 or 2) 

Text is the header contents 
Output: N lines of text 

Processing: Text is transferred from command file to report 

file with the first character being used for carriage control. 
Standard FORTRAN convention used for carriage control (for 
example, see next page). 


i 

j 

■ 

j 
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3. 3. 2. 2 Count Command 

Purpose: to print number of entries in a set with text comment. 

Input: HC SN, LOC, Text 

where : 

HC is the command 

SN is set number that count for which is printed 
LOC is column count where count is to be printed 
Text is the text data to be printed 
Processing: Text is transferred from command file to report 

file and number of entries is printed with it. The first text 
character is used for carriage control. 

3.3.3 SOFTWARE TO ELIMINATE REDUNDANT STORAGE 

The following new RIMS commands were designed in ojrder that 
certain data does not have to be stored redundantly in different 
FLOCON records. The DAPTS and FLOCON records of the ASATS 
data base will have a hierarchical relationship. The DAPTS 
record (the parent record) contains information common to 
several FLOCON records. , 

3. 3. 3.1 Generate Parent Set 

Purpose: To generate a set of parent records (DAPTS records, 

for ASATS) from a given set (FLOCON records, for ASATS) 

Input: GPSN 

where: GP is command 

SN is a set number 

Output: a set (next available set number) of parent records 

Processing: The parent record ID for each record ID in the 

input set is placed in the output set. 1 

3. 3. 3. 2 Generate Children Set 

Purpose: to generate a children set (FLOCON records in ASATS) 

for a set of parent records (DAPTS record in ASATS) . 


Input: GC SN 

where: GC is the command f 

SN is the parent set ^ 

Output: Parent set (whose set number is the next available 

set number) 

Processing: The record pointer address is computed for each 

record ID in the parent set. The addresses for potential 
children records (16 following parent records) is searched 
to determine if children records exist. Each child 
ID that is found is then transferred to the children set. 

3. 3. 3. 3 Display Data from Two Data Base Levels 

Purpose: To display a set of FLOCON records with information 

from the associated DAPTS records* as specified by a format. 

Input DA SN f FN 

where: DA is command 

SN is set number for a set of FLOCON records 
FN is format ID for displaying data 
Output: specified set in specified format on report file. 

Processing: The format for displaying data is retrieved. 

Then for each record ID in the input set the following actions 
are taken: 

a Get record ID from set 
a Retrieve record and associated format 

a’ Transfer data from the FLOCON record to an output buffer 
according to the display format 
a Generate record ID for associated DAPTS record 
a Retrieve DAPTS record and associated format 
a Transfer data from the DAPTS record to output buffer 
according to the display format 
a Write output buffer to identified file 
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3.3.4 ACCESS CONTROL 


The following new commands , software, and RIMS mods are 
defined to satisfy access control requirements. Each user 
will have an access control word. It will control what RIMS 
commands he can use. 

3. 3.4.1 Add Access Control Word 

Purpose: to add access control word for the data base 

Input: AC CW, BIT STRINg 

where: AC is the command 

CW is an 8 character access control word 
BIT STRING is a 24 character string identifying wuich 
commands the user having this access code can utilize 
Output: Access code and character string are stored in data 

base 

Processing! A record is generated containing the character 
string. A key is generated by concatenating @ with the 
character string. The record is posted to that key. Note:, 
a key with @ in the first position will not he displayed 
by the expand function. 

3.3.4. 2 Delete Access Control Word 

Purpose: to delete an access control word. 

Input: DC CW 

where: DC is the command 

CW is the access control word 
Output: None 

Processing: The record posted to the word CW is deleted and 

the key associated with the control word is deleted. 

3 . 3 . 4 . 3 Modifications to "Begin" Operation for Access Control 

Purpose: to allow identification of a user to RIMS by access 

control word 

Input changes: BE DBN, CW 

where CW is a control word 
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Output changes : None 

Processing changes: the record associated with the control 

word is retrieved. If a particular control word does not 
exist, RIMS is aborted. 

3. 3.4.4 Modification to RIMS Control Routine for Access Control 

Purpose: to prevent execution of unauthorized commands 

Output; Message to message file - 'Unauthorized command' 

Processing: Before calling subroutine to process the associated 

command the character string containing indicators of user's 
authorized commands is examined. If user is not authorized for 
the* command, the message is output and the subroutine is not executed. 

3.3.5 ARITHMETIC OPERATIONS 

A new RIMS command has been included to provide the typical 
statistical and arithmetic type aerations required by ASATS 
in the ad hoc environment. 

3. 3. 5.1 Compute Command 

Purpose: to provide for a set of records (1) summation of 

identified field, (2) mean of the difference of two fields, 

(3) standard deviation of the differences of two fields. 

Input: AR SN, RID, FI, F2 

where: AR is the command 

SN is the set number for which all computations 
are to be performed 

RID is the record ID for the record where the 
results of the computation are to be stored 
FI is a field name 
F2 is a field name 

Output: Sums of both fields, mean of difference, standard 

deviation of difference, count of number of records used in 
mean computation, and the count of the total number of records 
are stored in the specified record. 

Processing: Each record in a set is retrieved*.and processed. 


The following computation is performed for each record. 

• Each field is summed over all records in which both 
fields are not blank. 

• A count of the number of records is maintained. 

• For each record where neither field is blank 
e Count of the records is maintained 

• Sum of the difference of the two fields is maintained 

After all records have been processed, the mean and the standard 
deviation of the differences are computed. All computations 
are then stored in the specified record. 


3.3.6 MODIFICATION TO EXISTING COMMANDS 

In order to implement standard reports by executing a RMS' 
command file containing the RIMS commands far reports , two 
capabilities are needed., They af fi- 
ll Th# ability to generate null sets 

§ The ability to assign a file by name 

The following will provide these capabilities. 

3 . 3 . 6 . 1 Modification to Reassign File 

Input modifications: The current syntax is 

RF IU, EU 

where: RF is the command 

IU is the internal unit number 
EU.is the external unit number 
the syntax will bd modified to bfe: 

RF IU, EU, File Name 

so that if IU is 0 (zero) then EU is set to the included file name 
Output modifications: None 

Processing modification: If the internal unit is zero, the 

external unit is closed then opened with the specified file 
name. Otherwise processing is the same. 

3. 3.6. 2 Null Set Option 

Input: ZS OP 

where ZS is command 

OP is the option: 1 for null sets to be kept; zero for 

null sets not kept. At sign-on, the default mode of the 
system will be for null sets not kept. 

Output: None 

* 

Processing: A flag is set in a common block to indicate mode. 

* i * 
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3 . 3 , 6 . 3 Ch 


Routines for Null Sets 


Minor changes to the select, combine, specify and select* 
non-key functions will have to be made to allow generation of 
null sets. 
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3.4 THE PREPROCESSOR 

3.4.1 PURPOSE 

* 

The preprocessor produces several of the required audit report 
listings of the input update cards and acts as an interface 
between the un sorted, unedited input form and the for® of 
input required for the RIMS data management software. 

3.4.2 INPUT 

The Preprocessor accepts update cards of all types as described 
in the ASATS Specifications Document LEC-B675. The cards may 
be in any- order and must include ojne and only one Q card. 

The input cards for the Preprocessor must be surrounded by a 
proper set of batch control cards for the PDP 11/45 RSX-11D 
operating system. The proper sequence of control cards will 
be specified in the Operations Manual to be provided as part 
of this project. 

3.4.3 OUTPUT 

The output of the Preprocessor will be of two kinds. The first 
kind is the listings of input cards : 

• A listing of all cards in the order of their input 

• A listing of all cards having invalid card types 

• A listing of all cards rejected as duplicates 

• A listing of all cards submitted for this update run, 

sorted into order by card type. 

The second kind of output from the Preprocessor is a set of 
files of update card images which will serve as input to the 
RIMS system for actual update of the data base. These files 
ares 

• A file of all sets of *, 2, 3 cards, where a complete 
set is given for any segment 

t A file of *, 2, 3 cards in which only one or two of the 
cards appears for any segment 
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• A file of other update cards sorted into the order: 

Q, 4, 5, 6, B, 7, 8, 9, G, H, I, J, K, M, X, U. 

3.4.4 DESCRIPTION OF PROCESS 

The Preprocessor will consist of a sequence of operations 
performed by special-purpose FORTRAN programs and by calls 
to the RSX-11D system SORT utility program. Data flow for this 
sequence of operations is shown is figure 3-8. 

The first operation shown gives two of the output listings and 
separates the LACIE phases into separate files. The remainder 
of the data flow is shown for only one LACIE phase, the flow 
for the other phase being separate but of the same form. 

The second operation is performed by the RSX-11D system SORT 
utility, to put the cards into order by card type. 

The next operation shown is a separation of cards by type. 

The type *, 2, 3 cards will be sorted by segment number to find 
those segments for which all three are present and which may, 
therefore, be new segments for entry among the DAPTS records. 
Cards not part of a set will be sorted back into card type 
order with * cards first, then 2 cards, then the 3 cards. 

Cards of other types (4, 5, 6, B, 7, . . .) are put into another 
separate file. 


3-33 




RB- SORTED 
INTO ORDER 
*, 2,3 


FIGURE 3-8 
THE PREPROCESSOR 


(TO RIMS) 
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3.5 THE POSTPROCESSOR 


3.5.1 PURPOSE 

The Postprocessor is required because core space limita- 
tions impose a limit on the number of output files that can 
be defined in RIMS. RIMS will write several logical output 
files into one actual output file and attach a flag to each 
record to allow the Postprocessor to separate the output files 

3.5.2 INPUT 

Input to the Postprocessor is a file of information about 
updates made or attempted by RIMS. 

3.5.3 OUTPUT 

Output from the Postprocessor consists of one file of card 
images to be punched and several files of report listings, 
as follows: 

• Cards punched (4, 5, 6 cards for each *, 2, 3 set that 
created a new DAPTS segment record, and G, H cards punched 
for each B card that created a new FLOCON acquisition 
record) 

• A listing of the cards punched 

• A listing of all new DAPTS segment records added 

• A listing of invalid acquisitions (B cards for which no 
DAPTS record has the same segment number) 

• A listing of invalid attempts to modify a DAPTS record 
(modifications from *, 2, 3, 4, 5, 6 cards such that no 
existing DAPTS record has the given segment number) 

• A listing of invalid modifications to FLOCON records 
(no matching segment number and/or acquisition date for 
input G, H, I, J, K, M, U, X, 7, 8, or 9 cards) or a 
required data base field has never been set (as required 
for card types H, I, J, etc.). 
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3.5.4 PROCESS 

I t 

The Postprocessor will read the output file from RIMS and 
write into the proper output file(s) chosen on the basis of 
a flag included with each record from RIMS. See Figure 3-9. 




FIGURE 3-9 

ASMS - THE POSTPROCESSOR 
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3.6 ASATS STANDARD REPORTS 

All standard reports identified, as required for ASATS , can 
be produced using the RIMS commands (as augmented in section 
3.4 of this document) and the added output translation 
function. Once a data base has been established as described 
in this document , RIMS provides the functional capabilities 
required for these reports. 

In order to satisfy the standard report and ad hoc report 
requirements using the data base design as described in 
section 3.2, it is necessary to perform output translation 
for some parameters. Two methods of output translation are 
required. The first method would generate the output field 
value as a function of the input field value using a predefined 
table. The second method is identical except that the output 
translation occurs only if the output field contains a blank 
value (thus providing an override capability). 

Four tables are required for the necessary output translations. 
They are: 

• Current location table as a function of Acquisition Status 
Character 

• Current status table as a function of Acquisition Status 
Character 

• Current comment table as a function of Acquisition Status 
Character 

• Table indicating crop calendar, ancillary data and topo- 
graphic data status as a function of segment, status 
character. 

The contents of the first three tables are illustrated in 
Table 1 of reference 1. The fourth table is functionally 
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described in section 3.2.4 of reference I. 

Two additional data types are required for output processing. 
They are; 

• Type 6 - Perform output translation using current location 
table. 

• Type 7 - Perform output translation using current status 
table. 


For each data type, the input format specifies the location of 
data to be used for the table look-up. The output format 
specifies the location where the table results are to be placed 
in the output record. 

The approach for implementing these reports is to build 
separate files containing the necessary RIMS commands for each 
report. The report can then be produced by assigning the file 
as a RIMS command file. Batch decks will also be provided 
which will cause execution of these reports. 

The requirements for each report can be translated directly 
into RIMS commands. Therefore a discussion of individual 
reports is not included in this document. 



4. TEST PLAN 

* 

Three levels of testing will be performed for RIMS software. 

The three levels ere component , subsystem! and system where 
components are one or more subroutines working together. The 
Update Preprocessor! ypdate Postprocessor! RIMS, and ASATS 
reporting operations may be viewed as separate subsystems. 

Component level testing will be performed in an informal 
environment. Test procedures and results will not be documented. 

A formal acceptance test will be prepared and executed for 
RIMS, an ASATS subsystem. Demonstrations and test results 
will be made available to illustrate successful testing of 
other ASATS subsystems. Acceptance test procedures will be 
documented for ASATS, A preliminary version of these procedures 
will be executed with a system level test to illustrate system 
readiness for a parallel running of both the PDP 11/45 and 
COMSHARE version of RIMS. The ASATS data base on COMSHARE will 
be moved to this system. Both the PDP 11/45 and COMSHARE ASATS 
will process all updates and reports for two weeks. Upon 
successful completion of the parallel runs (both systems 
produce functionally identical results), the formal acceptance 
test with finalized procedures will be executed. 
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5. TRAINING PLANS 


Documentation will be provided to support the PDP 11/45 version 

of ASATS. Documents to be provided are: 

e Operations Document - it will contain the necessary 
instructions for the computer operator to (1) run the 
batch update programs, (2) run standard batch reports, 

(3) run the data base reorganization program, and (4) 
recover the ASATS data base. 

i 

e ASATS Users Document - it will cpntain (1) procedures for 
setting up an ASATS batch update deck, (2) guidelines on 
when to reorganize a data base, (3) procedures for creating 
a new data base. 

e Update RIMS USER Document - this document currently describes 
each RIMS command. A description of all new RIMS commands 
will be included. 

• User Training Course - a training course in the use of 
RIMS and ASATS will be provided. 


